ADR-002: Cloudflare边缘计算选型

ADR-002: Cloudflare边缘计算选型

背景与问题

松鼠提醒需要处理海量设备的实时状态上报，核心挑战：

  1. 超低延迟：用户状态上报需要<50ms响应
  2. 全球分布：用户遍布全球，需要就近接入
  3. 突发流量：早晚高峰流量可能是平峰的10倍
  4. 成本敏感：按请求计费，避免闲置资源浪费

问题：选择哪种边缘计算方案来处理状态上报和预处理？

考虑选项

选项对比表

维度 Cloudflare Workers AWS Lambda@Edge 腾讯云SCF Vercel Edge
全球节点 ✅ 250+ ✅ 400+ CloudFront ⚠️ 国内为主 ⚠️ 有限
香港延迟 ✅ <10ms ✅ <15ms ❌ 跨境>50ms ⚠️ ~20ms
冷启动 ✅ 0ms (V8 Isolate) ❌ 100-300ms ❌ 100-500ms ✅ 0ms
计费模式 ✅ 按请求/CPU时间 ❌ 按请求+持续时间 ❌ 按资源包 ✅ 按请求
免费额度 ✅ 10万/天 ❌ 无 ⚠️ 有限 ✅ 较宽松
生态集成 ✅ Durable Objects/R2 ✅ AWS生态 ✅ 腾讯云生态 ⚠️ 有限
KV存储 ✅ Workers KV ❌ 需DynamoDB ✅ Redis ❌ 需外部
WebSocket ✅ Durable Objects ❌ 不支持 ✅ 支持 ⚠️ 有限
成本估算 ¥5万/年 ¥20万/年 ¥15万/年 ¥8万/年

各选项详细分析

1. Cloudflare Workers（推荐）

  • 优点：
  • V8 Isolate冷启动时间为0，极致性能
  • 250+边缘节点，香港<10ms延迟
  • Workers KV全球同步，适合配置下发
  • Durable Objects支持有状态WebSocket
  • 成本最低，免费额度 generous
  • 缺点：
  • 运行时受限（不支持原生Node.js模块）
  • CPU时间限制（50ms免费/400ms付费）
  • 调试相对困难

2. AWS Lambda@Edge

  • 优点：CloudFront全球节点，与AWS生态集成
  • 缺点：
  • 冷启动100-300ms，不如Workers
  • 部署到CloudFront需要15-20分钟
  • 成本较高
  • 不支持KV原生存储

3. 腾讯云Serverless Cloud Function (SCF)

  • 优点：国内合规，与腾讯云产品集成
  • 缺点：
  • 香港节点有限，跨境延迟高
  • 冷启动时间较长
  • 主要面向国内用户

4. Vercel Edge Functions

  • 优点：开发者体验好，与Next.js集成
  • 缺点：
  • 节点数量不如Cloudflare
  • 企业级功能（如Durable Objects）缺失
  • 更适合SSR而非边缘计算

决策与理由

最终决策：选择 Cloudflare Workers

决策理由

  1. 延迟优势 ⭐⭐⭐⭐⭐
  2. 香港边缘节点延迟<10ms，满足实时状态上报需求

  3. 0ms冷启动，用户体验极致流畅

  4. 成本优势 ⭐⭐⭐⭐⭐

  5. 按请求计费，无闲置成本
  6. 预估年成本5万，比其他方案节省60%+

  7. 免费额度覆盖测试和小规模用户

  8. 架构契合 ⭐⭐⭐⭐⭐

  9. Workers KV适合存储用户配置和地理围栏数据
  10. Durable Objects可用于WebSocket推送提醒

  11. R2对象存储适合轨迹数据归档

  12. 全球分布 ⭐⭐⭐⭐⭐

  13. 250+节点覆盖全球主要城市

  14. Anycast自动路由到最近节点

  15. 技术栈匹配 ⭐⭐⭐⭐

  16. TypeScript/JavaScript支持良好
  17. 状态引擎逻辑轻量，符合CPU限制

风险与缓解措施

风险 影响 缓解措施
V8 Isolate限制（50ms CPU） 中 1. 复杂计算下沉到K8s
2. 优化算法复杂度
3. 升级付费计划（400ms）
无法使用原生Node.js模块 低 1. 使用Web标准API
2. 纯JavaScript实现核心逻辑
供应商锁定 中 1. 核心逻辑抽象为可移植代码
2. 保留迁移到标准Serverless的能力
调试困难 低 1. 使用wrangler本地模拟
2. 完善的日志和监控
Workers KV一致性（最终一致） 低 1. 配置数据允许延迟同步
2. 关键状态使用Durable Objects

分层架构设计

为避免Cloudflare Workers限制，采用分层架构：

Cloudflare Workers (边缘层)
  - 状态上报接收
  - 简单校验和预处理
  - 地理围栏匹配
  ↓
腾讯云K8s (逻辑层)
  - 复杂状态机计算
  - 业务逻辑处理
  - 大规模数据分析
  ↓
TiDB (数据层)
  - 持久化存储
  - 实时分析

实施计划

  1. Phase 1（1周）：Workers环境搭建，基础路由实现
  2. Phase 2（1周）：Workers KV配置存储，Durable Objects WebSocket
  3. Phase 3（1周）：与K8s服务联调，端到端测试
  4. Phase 4（1周）：灰度发布，性能监控

相关文档链接

🐿️ 松鼠提醒项目 | 架构师 @architect-lead | 已批准Cloudflare Workers作为边缘计算基础设施